Talk:JavaScript Cookbook
'Disabling wiki-wide scripts' implementation Regarding , I don't think worrying about browsers not supporting localStorage is a concern. If people are still using IE 7, Firefox 3, Chrome 4, or older, they'll likely be having greater issues than not being able to disable a wiki-wide script! Also, the main reason for my edit (other than simpler code) is that using localStorage directly will throw in a number of situations (e.g. Safari in private browsing mode, Chromium/Firefox with stricter-than-default privacy preferences). Using $.storage (note: not $.jStorage, as was mentioned in the edit summary) ensures that localStorage is safe to use before using it. - OneTwoThreeFall (talk) 05:35, October 10, 2016 (UTC) :Local storage has another problem. If it ends up full for whatever reason, it won't allow any more data. Cookies on the other hand can probably be added until the whole hard drive is full. A user probably wouldn't be able to browse anyway if the hard drive is completely full. Cookies also provide secondary storage in this case, although the current snippet doesn't check if the local storage is full anyway. This is why a fallback to using cookies makes sense. See: * https://phabricator.wikimedia.org/T66721 * http://stackoverflow.com/questions/13567509/what-happens-when-localstorage-is-full : Dessamator (talk) 08:27, October 10, 2016 (UTC) ::> Cookies also provide secondary storage in this case, although the current snippet doesn't check if the local storage is full anyway. ::Mmm, that's another case where localStorage can throw (and is precisely what happens on Safari in private browsing, where the quota is effectively set to 0). If it did throw in personal JS, any code after would not run and any fallback would not help, which would be confusing for the person using this code. Of course, this could be worked around by wrapping the whole lot in try...catch, but that'd make the code even larger… ::Personally, I'm not a fan of using cookies here as they add unnecessary overhead to every network request to wikia.com. Note that $.storage does have a fallback: it uses window.name (persistent within the same tab/window, but not across the whole session) if localStorage is not usable for whatever reason. - OneTwoThreeFall (talk) 10:53, October 10, 2016 (UTC) :::That's why these are snippets, and not full solutions. One solution would be to use the user options api, and to store this as a preference. But that isn't available and considering the costs of backporting vs the benefits of very few users actually using them, it is unlikely that Staff will be willing to backport it without a very strong usecase. Aside from the fact that using preferences to store arbitrary data is a very huge hack which probably shouldn't have been added to mediawiki core. :::> I'm not a fan of using cookies here as they add unnecessary overhead to every network request to wikia.com ::: Well few people probably like cookies, but they are a necessary compromise. This snippet is only a demo code anyway meaning that people are still free to adapt, discard portions, or change it to suit their needs. ::: Perhaps another page should be used for recommended coding techniques or practices. Although considering how chaotic this wiki is, it isn't likely that anyone would adopt said practices... Dessamator (talk) 11:09, October 10, 2016 (UTC) ::::Well sure, but it'd be good to have these snippets working best they can, making implementation easier. It'd be quite nice if the Options API currently available allowed custom preferences (for this and for other scripts, to allow using prefs without making people deal with JS variables and the like), but as you've said, it's unlikely to be ported. ::::Currently, the only time cookie fallback is used is in very outdated browsers not supporting localStorage. The current fallback is useless if localStorage has a problem, since it'll raise an exception (meaning any localStorage fallback not involving try...catch is useless). This is what I was trying to fix/simplify by using $.storage. ::::Hmm, that's a mostly unrelated note, but it would be nice to establish some JS coding techniques/conventions for this wiki, similar to what already exists for Lua. Either MediaWiki's or Wikia's conventions would serve well. Sure, the wiki's a little chaotic, but it couldn't hurt, right? - OneTwoThreeFall (talk) 04:32, October 11, 2016 (UTC) :::::In the long run, it's just personally maintained user scripts with wildly varying complexity. I think posting a condensed version of Wikia CC on a wiki page could be useful especially in helping people learn, but I'm not sure if it's worth it to actually attempt to enforce them. TK-999 (talk) 08:50, October 11, 2016 (UTC) :::::As nice as it would sound, I don't think it's possible to make all JS coders on this wiki follow a particular convention - some will prefer using pure JS and no jQuery, among other things. I think as long as the scripts have been made reasonably efficient in their design at run-time (such as reducing the number of GET requests made, caching mw.config.get('wgFoo') variables if they're using multiple times), no concrete conventions are needed. Ozank Cx (talk) 08:59, October 11, 2016 (UTC) ::::::(getting more off-topic!) I was thinking more as guidelines (or even learning tools, as TK-999 mentions), not steadfast rules. Note that the conventions don't necessarily refer to jQuery use, efficiency, etc. but more to code style (e.g. spacing, indentation, semicolon use). - OneTwoThreeFall (talk) 09:28, October 11, 2016 (UTC) :::::Feel free to either add the try .. catch to the existing code or to have an alternative section with your proposed solution. :::::As far as creating guidelines or recommendations go, I don't think it will be useful to anybody. As long as the wiki remains chaotic with the "admins" largely acting more as overseers than doing anything community related, and the scripters largely using it as a pastebin or waste dump. This would probably be wasted effort. Basically just creating recommendations for recommendation sake. :::::To give an actual real world example, the guidelines for lua aren't particularly followed possibly because lua is not popular, and primarily because there is no enforcement. All scripts that attempt to follow some of those guidelines were written either collaboratively by me and / or DarthKitty (people who were involved in its creation). :::::It is rather unfortunate though, because when these scripts break users expect someone to step in and fix them, and those courageous enough to do it will always find it difficult to follow an undocumented, sometimes badly written and largely random code. The vicious cycle simply continues thereafter.Dessamator (talk) 12:02, October 11, 2016 (UTC) ::::::Alright, I've added it as an alternative section. Using try...catch would make the existing code even larger, which doesn't seem desirable. ::::::Perhaps the wiki is chaotic because there are few guidelines and not all that much oversight? (or perhaps I'm just optimistic?) - OneTwoThreeFall (talk) 11:51, October 12, 2016 (UTC) :::::::Thanks. :::::::Part of the problem is that a mediawiki was not designed to host running code, it has no support for testcases, pre-submit processes, and minimal checks. Scribunto is actually better at this because it can verify that the code contains no fatal syntax errors before saving. At this point it is just a matter of server side configuration to make this compulsory. The main problem is that the wiki has no "community", and is more like the wild west. :::::::If it did have it, then guidelines would have naturally have been created and enforced, just like any other wiki. This is primarily caused by the fact that programming is hard, and 99% of the wiki users can't contribute to it. Script users don't particularly care about the wiki, they care more about getting what they want (complain) and leaving. :::::::You are free to try to create those guidelines and who knows maybe it'll spark some interest. Dessamator (talk) 18:32, October 12, 2016 (UTC) ::::: Why would you actively try to enforce something as small and as insignificant as spacing guidelines and such. If anything that will lead to nothing more than a lot of work for admins trying to fight an uphill battle. ::::: Not to mention a headache for people who don't write javascript but instead another language that then compiles to javascript (and then hopefully minifies it). ::::: जसले मह काढ्छ उसले हात चाट्छ 17:03, October 12, 2016 (UTC) ::::::It was only an idea. I see that people disagree, so I'm not planning to take it any further. Also note that a guideline, by definition, wouldn't need to be enforced; it is just a suggestion. - OneTwoThreeFall (talk) 17:41, October 12, 2016 (UTC) ::::: Even Staff believes we could use some more administrative oversight. I contacted them last week about the possibility of appointing a second non-Staff admin or content mod to assist Cqm with housekeeping and general wiki cleanup, and I got back this response from the Director of Technical Support: "I certainly agree that DEV could use more administrators, however we've not had any major code editors step up and show interest... Cqm is certainly free to hold an election or approach other users he would be comfortable having on his team." I suppose one of you long-time users could step up to the plate and make a case for user rights if you felt strongly enough about the need for clearer guidelines and better organization around here. [[User:Count of Howard|'Count of Howard']][[User talk:Count of Howard|'(talk)']] 18:25, October 12, 2016 (UTC) ::::::I don't think having access to delete and block functions will change things much on this wiki. If anything the organisation of the wiki itself needs to be improved first. Ozank Cx (talk) 19:18, October 12, 2016 (UTC) :::::On the subject of "people who don't write javascript but instead another language that then compiles to javascript (and then hopefully minifies it"—minified code should not be posted here anyways. ResourceLoader takes care of minification. There is no need to double minify, all you achieve is you make the code completely unreadable to everyone. TK-999 (talk) 19:06, October 12, 2016 (UTC) :::::: For code that is generated from another form the compilers usually minify the resulting javascript as well as performing DCR. In such cases as compiler generated code it is not helpful to have the non-minified version anyway as that is not what you are writing nor is it what people should be making changes to. In such cases where you are writing code in another language, say Elm, you should post the Elm source file as well as the code compiled from it so that if people want to adapt and change it they can. :::::: While you can technically beautify the output of the compiler it just adds another unnecessary step since it will be both cryptic and hard to read (since it was generated by a machine) as well as it being minified again in a later step. If you want to one could post three files when publishing a script written in this way. You could post the Elm source file (script.elm), the beautified compiler output (script.js), and the output itself (script.min.js). :::::: Even so that does nothing to subtract from the fact that compiler generated code will not be as neat and as readable as code written by hand. :::::: जसले मह काढ्छ उसले हात चाट्छ 23:15, October 12, 2016 (UTC) ::::::I'm not sure if using any to-Javascript compiler has any advantages in a Wikia user script context. Even the largest scripts here are rather simple projects. TK-999 (talk) 08:48, October 13, 2016 (UTC)